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Abstract 
This document updates the Multi-threaded Routing Toolkit (MRT) export 
format for Border Gateway Protocol (BGP) routing information by 
extending it to include optional terrestrial coordinates of a BGP 
collector and its BGP peers. 
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1. Introduction 


Researchers and engineers often wish to analyze network behavior by 
studying routing protocol transactions and routing information base 
snapshots in relation to geographical topologies. Usually, the 
Border Gateway Protocol [RFC4271] is the subject of study, and the 
analysis can be significantly aided by the availability and extension 
of the "Multi-Threaded Routing Toolkit (MRT) Routing Information 
Export Format" [RFC6396]. The MRT format was originally defined in 
the MRT Programmer’s Guide [MRT-GUIDE]. 


The addition of geo-location coordinates (longitude and latitude) 
pertaining to the geographical location of both the BGP collector and 
its BGP peers to BGP export data enables a researcher or enquiring 
individual to gain a terrestrial insight to the routes seen by a BGP 
speaker. Such data may ultimately aid researchers in understanding 
any disparity between the geographical location of networks and the 
topological location of networks in addition to the relationships 
between geographical position and routing anomalies. Such insight 
could provide future input into network design and network security. 


This memo documents an optional extension to the MRT format [RFC6396] 
and introduces an additional definition of an MRT Subtype field that 
includes the terrestrial coordinates of a BGP collector and its BGP 
peers. 


2. Requirements Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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3. Definitions 


Coordinates: The geographic latitude and longitude specifying a 
location on the earth. 


BGP Speaker: A network device that exchanges network routing 
information using BGP. 


Geo-location: Assigning a set of coordinates to a specific artifact, 
in this case a BGP speaker. 


BGP Collector: A BGP speaker (usually passive) that stores and 
archives BGP routing data from active BGP peers for analysis. 


BGP Peer: Either an internal or external BGP peer [RFC4271]. 
Not A Number (NAN): Numeric data type representing an undefined or 
unrepresentable value, as defined in the IEEE Standard for Floating- 


Point Arithmetic [IEEE754]. 


4. Geo-Location-Aware MRT Routing Information Subtype 


An additional subtype (GEO_PEER_TABLE) is defined for the 
TABLE_DUMP_V2 format, extending TABLE _DUMP_V2 Type. 


4.1. GEO_PEER_TABLE 


The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_V2 Types to include 
geo-location information in the form of the World Geodetic System 
1984 (WGS84) [WGS-84] formatted coordinates. 


The document adds the 7th subtype number and name below. The first 6 
subtypes are defined by the MRT format [RFC6396]. 


Subtype Number Subtype Name 


y GEO_PEER_TABLE 


The GEO_PEER_TABLE MRT record provides the BGP ID of the collector, 
its latitude and longitude in WGS84 [WGS-84] format, and a list of 
indexed peers and their respective latitudes and longitudes in WGS84 
[WGS-84] format. 


The format and function of the Collector BGP ID and Peer Count are as 
defined by the TABLE_DUMP_V2, PEER_INDEX_TABLE format [RFC6396]. 
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The Collector Latitude and Collector Longitude are the geographical 
coordinates of the collector in WGS84 [WGS-84] datum decimal degrees 
format stored as a single precision float in the 32 bits allocated to 
the Collector Latitude and Collector Longitude. The latitude and 
longitude MAY be a Not A Number (NAN) [IEEE754] for situations where 
the geo-location of the collector is considered private. The 
Collector Latitude and Collector Longitude MUST NOT be a mix of WGS84 
[WGS-84] datum coordinates and NAN values. 
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Collector BGP ID | 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Collector Latitude | 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Collector Longitude | 


—t-4-4-4+-4+-4-4-4-4-4-4-4-4-F-t-t-t-tat-t-t-t-t-4t-4-4-4-4 
Peer Count | Peer Entries (variable) 
—+-4-4-4+-4+-4-4-4-4-4-4-4-4-4-t-t-t-t-t-t-4t-4F-4F-4-4-4-4-4 


Format of the GEO _PEER_ TABLE 


The format of the Peer Entries is shown below. The Peer Type and the 
Peer BGP ID are as defined in the TABLE DUMP_V2 MRT, PEER_INDEX_TABLE 
format [RFC6396]. 


The order of the Peer Entries in the 


GEO_PEER_TABLE MUST match the order and number as existing in the 
PEER_INDEX_TABLE. 
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-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+-+-++ +++ 
Peer Type | 
-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Peer BGP ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Peer Latitude | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Peer Longitude | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Format of Peer Entries 


The Peer Latitude and Peer Longitude are the geographical coordinates 
of the peer in WGS84 [WGS-84] datum decimal degrees format stored as 
a single precision float in the 32 bits allocated to the Peer 
Latitude and Peer Longitude. The latitude and longitude MAY be a Not 
(NAN) [IEEE754] for situations where the geo-location of the 


A Number 
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peer is considered private. The Peer Latitude and Peer Longitude 
MUST NOT be a mix of WGS84 [WGS-84] datum coordinates and NAN values 
for a single peer. 


4.2. GEO_PEER_TABLE and Peer Entry Values 
Collector BGP ID: Defined in the MRT format [RFC6396]. 


Collector Latitude: Geographic latitude of the BGP collector in WGS84 
[WGS-84] datum decimal degrees format stored as a single precision 
float. 


Collector Longitude: Geographic longitude of the BGP collector in 
WGS84 [WGS-84] datum decimal degrees format stored as a single 
precision float. 


Peer Count: Defined in the MRT format [RFC6396]. 
Peer Entries: Defined in the MRT format [RFC6396]. 
Peer Type: Defined in the MRT format [RFC6396]. 
Peer BGP ID: Defined in the MRT format [RFC6396]. 


Peer Latitude: Geographic latitude of the BGP peer in WGS84 [WGS-84] 
datum decimal degrees format stored as a single precision float. 


Peer Longitude: Geographic longitude of the BGP peer in WGS84 
[WGS-84] datum decimal degrees format stored as a single precision 
float. 


5. BGP Collector Construction 


This section aids the reader in understanding the function of a BGP 
collector. 


The BGP collector is a hardware- or software-based device that speaks 
the Border Gateway Protocol. Its intended function is to store (and 
archive) the BGP routing data it receives from other BGP speakers 
with which it has peering relationships, providing data for later 
analysis. The general nature of a BGP collector is that it isa 
passive device in that it listens to route updates and does not 
announce or propagate any information it knows or receives. It 
should be noted that this is not always the case; network operators 
sometimes enable the collection of BGP routing data on active BGP 
speakers to obtain a situational view of the routing system as they 
see it at a particular point in time. 
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As a fully fledged BGP speaker, the BGP collector can fit into any 
BGP topology including Internal BGP (iBGP), External BGP (eBGP), and 
so on. The implementation of a BGP collector in a network topology 
is therefore limited by that network’s use of BGP. 


6. Privacy Considerations 


The GEOPRIV [RFC6280] architecture requires that privacy rules 
attached to a location object be transmitted alongside the location 


information in the object. If a BGP collector adds location 
coordinates to an MRT record based on GEOPRIV location objects, then 
it would have to include privacy rules as well. Since the MRT geo- 


location format does not support the provision of privacy rules, each 
location entry in an MRT object is assigned the following default 
privacy rules [RFC4119]: 


-- retransmission-allowed: True 

-- retention-expires: 100 years from timestamp of the MRT object 
-- ruleset-reference: Empty 

-- note-well: Empty 


Location information derived from a location object with more 
restrictive privacy rules MUST NOT be included in an MRT geo-location 
record unless there are non-technical measures in place that enforce 
and communicate the constraints on the use of the location 
information in the MRT geo-location format (e.g., contractual 
agreements between peers). 
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8. IANA Considerations 


Per this section, the Internet Assigned Numbers Authority (IANA) has 
registered the additional Subtype code value as: 


7 GEO_PEER_TABLE 


in the MRT format [RFC6396] and Subtype code values related to the 
TABLE_DUMP_V2 Type in the MRT namespace. 
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9. Security Considerations 


This extension to the MRT format [RFC6396] defines fields that are of 
a descriptive nature and provides information that is useful in the 
analysis of routing systems. As such, the author believes that they 
do not constitute an additional network-based security risk. It is 
recommended that the operators of the BGP collector and BGP peers 
consider their own privacy and security concerns before supplying 
geographical coordinates to BGP data collection systems. Special 
attention should be given to the physical security of an organization 
before supplying geographical coordinates, especially if the 
resulting BGP data with geo-location extensions is made public. 


Entities that operate BGP collectors, and users of data provided by 
BGP collectors, should be aware that the geo-location data supplied 
by a peer can only be taken at face value. It is possible that a BGP 
peer may supply coordinates that are purposefully misleading or 
inaccurate. It is therefore up to the BGP collector whether or not 
to include this information or use its own methods to either trust or 
validate the data provided. It is not recommended that a BGP 
collector use geographical coordinates not supplied by a BGP peer. 
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